Choosing single or multiple appservers

■ iMISpublic (IIS application /iMISpublic) supports Public users; install it only if you are extending iMIS access to members through a non-CM public website.

Although these applications are largely independent of each other, they share two things:

■ Database: They share the same iMIS database and store much of their configuration information there. Many parameters for iMISpublic are defined through iMIS.

■ Logon: All logon handling is performed by iMIS (in conjunction with the ASP.NET authentication store), so iMISpublic forwards logon requests to iMIS. User records and their corresponding authentication record in the ASP.NET authentication store are global for all applications servers that share the same iMIS database.

For a simple client-server configuration, just use the iMIS installer to perform a Complete installation on a single appserver. This results in one instance of each application on one appserver, supporting all three user classes. After installation, you complete essential configuration, after which you can roll out clients to your users.

To create sophisticated configurations that distribute the applications among two or more appservers, you need to perform a Custom installation on each appserver. During a Custom installation, you can specify which applications to install. On some appservers, you might install both applications; on other appservers, you might install only one.

The iMIS architecture is flexible: you can install both applications onto the same application server (appserver), or you can install them on different appservers.

You can use the Multi-Instance Utility to install multiple instances of each application among multiple appservers. You might deploy a complex iMIS architecture like this to manually distribute client-server load in a large organization by spreading the workload across more appservers.

Note: Web farm architectures are not natively supported by iMIS. In a multi-appserver architecture, each application instance is independent of the others (apart from using the same iMIS database and sharing configuration and logon information). Authentication tickets are not shared among the instances, and there is no automated fail-over or load-balancing code written into either of the applications.

If you have custom ASP.NET extender applications, you can potentially integrate them with the iMIS applications to the extent possible within the framework of ASP.NET.

Caution! Any such integration or other customization of iMIS is beyond the scope of ASI Support; test carefully, and have a back-out plan if your customizations interfere with basic iMIS functionality.